Es wird eine Anzahl von unterschiedlichen Strategien für unterschiedliche Feinabläufe definiert. Die unterschiedlichen Strategien sind beliebig austauschbar.
Für unterschiedliche Konfigurationen der Fertigungszelle sind unterschiedliche Abläufe für die Bearbeitung der Werkstücke nötig. Wird die Anpassung an die aktuelle Konfiguration in der Ablaufsteuerung der Klasse ProcessingControl vorgenommen, führt dies zu Problemen:
Die Schwierigkeiten treten auf, weil Teile des Algorithmus für die Ablaufsteuerung variabel gehalten werden müssen. Das Entwurfsmusters Strategy nach [Gamma et. al., 1995] zeigt hier einen Lösungsweg auf. Mit Hilfe des Entwurfsmuster wird der Algorithmus in zwei Teile geteilt. Der eine Teil ist konstant und braucht bei Veränderung der Konfiguration der Fertigungszelle nicht verändert werden. Der andere Teil ist abhängig von der Konfiguration der Fertigungszelle. Für diesen Teil werden mehrere Klassen definiert, wobei jede dieser Klassen jeweils einen Algorithmus für eine Konfiguration der Fertigungszelle enthält. Durch Austausch der Klassen ist dann eine leichte Anpassung möglich.
Um dies zu vermeiden, werden die Abläufe in einen Grobablauf und einen Feinablauf unterteilt. In dem Grobablauf wird der Teil der Ablaufsteuerung, der unabhängig von der aktuellen Konfiguration ist, definiert. Dieser Grobalauf wird weiterhin in der Klasse ProcessingControl implementiert. In den Feinabläufen werden die Anpassungen an die aktuelle Konfiguration vorgenommen. Die Feinabläufe werden in eigenen Klassen implementiert. Wobei durch die abstrakte Klasse Strategy eine einheitliche Schnittstelle zur Verfügung gestellt wird. Von dieser Klasse werden neue Klassen abgeleitet und in diesen werden dann die unterschiedlichen Feinabläufe implementiert
Das Strategy-Muster nach [Gamma et. al., 1995] wird verwendet, weil sich das Verhalten der Ablaufsteuerung ändern muß, wenn z.B. ein anderer Greifer benutzt wird. Dies würde ohne das Entwurfsmuster zu komplexen Fallunterscheidungen in der Klasse ProcessingControl führen.
Die Bereitstellung unterschiedlicher Feinabläufe mit Hilfe des Strategy-Muster hat die folgenden Vorteile bzw. Nachteile.
Durch das Strategy-Muster werden Fallunterscheidungen vermieden. Wenn in der Klasse ProcessingControl der komplette Ablauf beschrieben wird, muß mit Hilfe von Fallunterscheidungen ein für die konkrete Konfiguration richtiger Algorithmus gefunden werden. Mit dem Strategy-Muster wird durch einen Methodenaufruf der richtige Algorithmus gefunden.
Beim Strategy-Muster muß man beachten, daß die Klasse ProcessingControl mit Hilfe der Klasse ProcessingMediator alle unterschiedlichen Strategien und ihre Unterschiede kennen muß. Nur wenn bei der Auswahl der Strategie alle Kriterien, in welchen sich die Strategien unterscheiden, berücksichtigt werden, wird die richtige Strategy ausgewählt. Damit muß bei Erweiterung der Kriterien auch die Schnittstelle der Klasse ProcessingMediator geändert werden. Denn der Methode SetStrategy werden die Parameter zur Auswahl übergeben und bei einer Erweiterung um andere Kriterien müssen auch für diese Daten übergeben werden, damit die richtige Strategy ausgewählt werden kann.
In das Strategy-Muster wird ein Mediator-Muster integriert, damit die Schnittstelle der Klasse ProcessingControl kleiner wird. Nach dem Strategy-Muster muß die Klasse ProcessingControl den Strategy-Klassen einen Zugriff auf die Maschinen ermöglichen. Übernimmt die Klasse ProcessingControl selbst diese Aufgabe, wird die Schnittstelle dieser Klasse sehr groß und damit schlecht wartbar. Durch die Einführung des Mediator-Musters nach [Gamma et. al., 1995] werden die Funktionen für den Zugriff auf die Maschinen aus der Klasse ProcessingControl herausgenommen.